Hackers Underworld 2: Forbidden Knowledge/Hackers Underworld 2: Forbidden Knowledge.iso/VIRUS/V101PT2

Text File | 1989-04-26 | 19KB | 298 lines

Portal-Rmail-To: [e-mail]
Received: by portal.com (3.2/Portal 8)
    id AA13156; Wed, 26 Apr 89 01:38:23 PDT
Received: from Sun.COM (arpa-dev) by sun.Sun.COM (4.0/SMI-4.0)
    id AA18522; Tue, 25 Apr 89 23:07:59 PDT
Received: from sun by Sun.COM (4.1/SMI-4.0)
    id AB12617; Tue, 25 Apr 89 23:07:12 PDT
Message-Id: <[e-mail]>
Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.Edu (IBM VM SMTP R1.2) with BSMTP id 5945; Wed, 26 Apr 89 02:02:46 EDT
Received: by LEHIIBM1 (Mailer R2.03A) id 5720; Wed, 26 Apr 89 02:02:42 EDT
Date:         Wed, 26 Apr 89 02:02:41 EDT
From: Revised List Processor (1.5o) <[e-mail]>
Subject:      File: "V101 2" being sent to you
To: "Gary F. Tom" <sun!portal!cup.portal.com!garyt>

Subject: Virus 101 - Chapter 2
From: [e-mail] (George Woodside)
Newsgroups: comp.sys.atari.st,comp.sys.apple,comp.sys.mac,comp.sys.ibm.pc
Date: 6 Mar 89 14:00:21 GMT
Reply-To: [e-mail] (George Woodside)
Organization: Citicorp/TTI, Santa Monica

In response to a lot of the mail I've received:

1) You haven't missed the "rest of the chapters". I'm posting them as I
   get them written.

2) You may not agree with me. I tried to set down the definitions and
   terms as I would be using them, for the benefit of those who weren't
   familiar with them. This whole area is rather vague, and most of us
   in the trenches and making up the rules, as we learn the game.

When we left our virus at the end of Chapter 1, it had managed to get itself
installed in our system by being present on the boot sector of a disk in the
machine at cold start or reset.

Another way a virus may be installed is via a trojan horse program. Trojan
horses come in many flavors. Some disguise themselves as programs which
provide some useful function or service, while secretly doing something
else. The something else may be installing a virus, sabotaging some part of
a disk, setting up hooks to steal passwords on time sharing systems, or
whatever else you can imagine. In the event of the virus installer, the
trojan horse has a bit more flexibility than a typical boot sector virus,
simply because it doesn't have to fit itself into a relatively small space.
Since it is hiding in a larger program, it can be whatever size is necessary
to accomplish the task.

A typical boot sector contains information about the layout of the disk it
resides upon. This block of data requires 26 bytes. The first three bytes of
the boot sector are left available for an assembly language "jump" command,
to allow the execution of the code to skip over the boot sector's data
block. And, the boot sector must add up to the proper magic number to have
executable status. That will require another two bytes, since the checksum
is a 16 bit value. So, 31 bytes are allocated. Since (at least in the 68000
family) machine instructions are always 16 bits and must begin on an even
address, 32 of the 512 bytes in the boot sector are not available to any
executable program. So, there are 480 bytes available for the executable
code. Machine instructions vary in length, depending upon what they do, and
how much additional information is required. In the 68000, instruction
lengths vary from one to five words, but a reasonable average instruction
length for a program is just over two words. That translates the 480 bytes
to 120 instructions.

The virus must contain the code to install itself, reserve the memory it
occupies to keep subsequent programs from over-writing it, spread itself to
other disks, and whatever it really intends to do once it decides it is time
to act. That's quite a bit of code to fit into 120 instructions, unless it
extends itself by loading some other part of the disk, or a file.

Files are pretty much out of the question. Most computer users would notice
if some file they didn't recognize started popping up on a lot of their
disks. There are attributes settable in a disk directory which can be used
to tell the operating system that certain files are "Hidden" or "System"
files. If the file had the proper status bits set, it could prevent itself
from appearing in normal disk directory displays. There are, however, more
flexible disk directory listing programs which will display the entries for
these files, as well as normal files. There is also the problem of the space
the hidden file occupies, as well as the directory entry. The space
available on the disk will be less than it should be, since the hidden file
is present. These symptoms would not escape detection for long.

A more effective method is the use of specific disk sectors. The standard
disk layout covered in the preceeding chapter mentioned such things as File
Allocation Tables, and disk directory space. In a standard format Atari
disk, for example, each FAT is 5 sectors long, and the directory is 7
sectors long. That is more than enough FAT space to accomodate the entire
disk. A virus in need of more space than 480 bytes might write the remainder
of itself in the last sector of the FAT (I have one that does this). It
might also write itself in the last sector of the directory, taking
advantage of a quirk in the operating system.

When a disk is formatted, all data sectors are normally filled with a
pre-defined value, E5 (hexadecimal). The directory and FAT space is usually
set to 00. When a directory entry is made active, the file name is written
in the directory, along with some other required information. When a file is
deleted, the first byte of the directory entry is set to E5. That makes the
entry available again. This is a carry over from the early days of floppy
disks, when where the directory would exist on a disk was not as well
defined. The directory entries had to appear as empty on a freshly formatted
disk, so E5 was used as a deleted entry mark. That way, no matter where the
directory was, a freshly formatted disk would always appear as empty. Now,
since disk formats are more flexible, the directory is located by
parameters, and normally the entire directory space is zeroed at formatting
time. Since an active entry will have some legitimate ASCII character in the
beginning of the file name, and a deleted entry will have E5 in the first
byte, it is generally assumed that encountering a directory entry with a
value of 00 in the first byte indicates that the entry has never been used.
Since directory entries are used (and deleted ones re-used) on a first-found
basis, finding one with 00 means that not only has it not been used, but
none of the ones following it will have been used either. Consequently, most
software stops looking at the directory entries when a 00 entry pops up. If
there are several more sectors available, there may be something hiding out
there, beyond the last used entry. While this method of hiding is not
foolproof, the typical virus is not concerned about being bulletproof in all
cases. It just has to survive long enough to reproduce itself, and it has
half the battle won. As long as it keeps spreading, sooner or later it will
survive long enough to do the task it is designed to do, then it wins both
halves of the battle.

There are other ways for the virus to get additional disk space. Typically,
floppy disks are not used up a sector at a time, but rather in groups of
sectors. Each group of sectors is referred to as a data "cluster". The
number of sectors in a cluster is variable, and is one of the parameters
stored in the boot sector. If the number of data sectors on the entire disk,
minus the boot sector, FATs, and directory, is not an exact multiple of the
number of sectors in a data cluster, the remaining sectors will never be
used by the opearting system. A clever virus can find them and hide there.
The inconvenience of this is that the unused sectors would normally be at
the end of the last track of the disk, causing long (and noticeable) disk
seeks to load or spread the virus.

There is a parameter in the boot sector designed to permit the disk to have
sectors reserved for any purpose, and not access